SECURITY NOTES ( incomplete) :
Author:
RAMU MEDA
Date: 01/sep/03
Fundamental goals of security, which are:
·
protection of data from
unauthorized reading or modification,
·
protection of computer
resources against unauthorized use, and
·
guaranteeing correctness and
availability of resources and data for authorized persons and entities
Downloaded Code, Applets, and the
Java Security Manager
- Java doesn't apply security rules specifically to instances of
subclasses of the java.applet.Applet class. Rather, it uses a security
manager to apply rules to all classes
- Generally, the security manager applies restrictions to all
classes except those that are loaded from the system's boot classpath
- The boot classpath is the list of locations from
which core classes are loaded. Usually, this is restricted
to the jarfiles in the directory jre/lib under the main Java installation
- In a Java application, the security manager is not installed
unless you deliberately install it.
- using System.setSecurityManager(new SecurityManager());] or
- from the command line
[using java -Djava.security.manager].
- If code is running in a browser, it is important
that the security manager should be installed by default,
and that is handled by the browser itself.
What Does the Security Manager Prohibit?
- The security manager works by checking whether a particular permission
is granted to the requesting class
- A permission is represented by a class describing
the general permission
- Instances of the permission class describe the permission in
more detail by adding a name and an action. The name and
action are optional in some permission classes, but when used,
they qualify the exact behavior that is to be allowed. For example, the
permission class java.io.FilePermission can be granted with the name “read”
and the action “/tmp/*”. This grants permission to read any file in the
/tmp directory (but not subdirectories).
- The permission mechanism is extensible, so you
can add new permissions
Permitted Operations to the Untrusted Code (applets) :
- ability
to create a thread,
- limited
ability to manipulate threads in the thread group that the browser created for the applet,
- ability
to perform essential manipulation of the AWT event queue so
that a GUI operates correctly,
- limited ability to read but
not modify some system properties.
- Generally
permitted to make network connections to the host from which it was
loaded.
Why the applet is prevented from
connecting to other hosts
1. If an applet could make arbitrary connections to any hosts, then
applets could be used as the origin for denial of service attacks
against other systems.
2. However, the original reason that arbitrary network connections are
prohibited is simply that many systems grant privileges to network requests
based on the origin IP address of that request. If an applet
could connect to arbitrary hosts, it would be possible for it to connect to a
server inside your corporate network. If that server grants access to your
machine based on IP address, then it will grant access to the applet, because
it is sending requests from your machine. The applet could then obtain
sensitive information and pass it back to its author, which you do not want to
allow.
Denied Operations:
- Any
operation that might be used to compromise the host is
denied. The only exceptions to this are
- CPU usage, Memory usage, and Network
bandwidth usage.
- Although
an applet can read keystrokes that are sent to it, it should
not be able to read keystrokes that are intended for other parts of the
browser or other programs running on the host system.
- Although
applets can make normal TCP/IP connections only with the host from which
they were loaded, it is possible for them to send data to any cooperating
host on the Internet
Java WebStart
- provides
all the benefits of applets and addresses the problems that make applets
less than satisfactory
- simplifies
corporate system maintenance and thereby enhances security
- Java
WebStart provides a small window that presents icons in a manner similar
to a Windows desktop. These icons do not necessarily describe installed
applications, but are typically links to code on a Web server somewhere
- When you
launch one of the applications shown in the Java WebStart desktop, the
classes needed to run that application are downloaded from the Web server.
This behavior is similar to that of an applet. However, once downloaded,
the classes are stored locally. This allows for a faster startup on
subsequent uses of the application.
- Better
yet, each time you try to run that application, the system checks to see
if any updates are available on the Web server, and if any updates exist,
just the needed changes are downloaded. This ensures that the application
is always ready to run, even if your computer is not connected to the
network, while also ensuring that the most up-to-date version possible is
used.
- the most
significant feature of Java WebStart is that it provides a modified
sandbox model. Specifically, the security manager used in Java
WebStart does not necessarily reject any request for privileged behavior.
Rather, it can be configured easily by either the system administrator or
the user to allow such behavior when it is deemed appropriate.